<?xml version='1.0' encoding='utf-8' ?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
		<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
		<title>GitAdapter</title>
		<link type="text/css" rel="stylesheet" href="PLUGINS_ROOT/org.polarsys.capella.doc/html/styles.css"/>
	</head>
	<body>
		<h1 id="Tutorials">Tutorials</h1>
		<p>These tutorials assume that you are familiar with Git and you know how it works.
			<br/>
			If you are new to Git or to distributed version control systems generally, then you might want to read 
			<a href="/wiki/../help/topic/org.eclipse.egit.doc/help/EGit/Git_For_Eclipse_Users/Git-For-Eclipse-Users.html" title="../help/topic/org.eclipse.egit.doc/help/EGit/Git_For_Eclipse_Users/Git-For-Eclipse-Users.html">Git for Eclipse Users</a> first.
			<br/>
			More background and details can be found in the on-line book 
			<a href="https://git-scm.com/book/en/v2" target="_blank">Pro Git</a>.
		</p>
		<p>Capella Git Adapter is based on EMF Diff/Merge, help and details about it can be found in the
			<a href="/wiki/../help/topic/org.eclipse.emf.diffmerge.doc/html/EMF-DiffMerge.html" title="../help/topic/org.eclipse.emf.diffmerge.doc/html/EMF-DiffMerge.html">EMF Diff/Merge Guide</a>.
		</p>
		<table border="1">
			<tr>
				<td>
					<p>
						<img height="48" width="48" border="0" src="images/Information.png"/>
					</p>
				</td>
				<td>
					<b>Please consider the given process instructions:</b>
					<br/>
					<p><ul>
<li>Always validate your model before a commit.</li>
<li>Select all fragments on commit if the model is fragmented.</li>
<li>Close the session before a pull, rebase or merge operation.</li>
<li>To handle large files in Git Repositories, more than 2GB, there are multiple 3rd party implementations that will try to solve the problem, many of them using a similar paradigm as a solution.</li>
<li>The content of all model files (aird, airdfragment, capella, capellafragment, afm, ...) are declared as ASCII Text and not binary files.
						<br/>(see Capella : Window &gt; Preferences &gt; Team &gt; File Content)</li>
</ul>
					</p>
				</td>
			</tr>
		</table>
		<h3 id="Basic_Tutorial">Basic Tutorial</h3>
		<p>This tutorial provides a step by step walk-through of the Capella Git Adapter.</p>
		<h4 id="Git_perspective">Git perspective</h4>
		<p><ul>
<li>To open the Git perspective: go to menu Window &gt; Perspective &gt; Open perspective &gt; Other... &gt; Git.</li>
</ul></p>
		<h4 id="Creating_Repositories">Creating Repositories</h4>
		<table border="1">
			<tr>
				<td>
					<p>
						<img height="48" width="48" border="0" src="images/Information.png"/>
					</p>
				</td>
				<td>
					<b>Some considerations for Git Repositories to be used in Capella:</b>
					<br/>
					<p><ul>
<li>Don't create the Repository within the Capella workspace.</li>
<li>Don't create a Repository with a Capella project as root.</li>
</ul></p>
				</td>
			</tr>
		</table>
		<ul>
			<li>In the Git Repositories view, create a new Git Repository: click "Create a new local Git repository".
				<br/>
				<br/>-
				<img height="498" width="531" align="middle" border="0" src="images/CreateRepo.png"/>
			</li>
		</ul>
		<p>
			<br/>
		</p>
		<ul>
			<li>In the opened wizard, select a path on your file-system to a non-existing folder, click Finish.
				<br/>
				<br/>-
				<img height="359" width="441" border="0" src="images/CreateRepoWizard.png"/>
			</li>
		</ul>
		<p>
			<br/>
		</p>
		<ul>
			<li>The created Git Repository will be shown in  the Git Repositories view.
				<br/>
				<br/>-
				<img height="520" width="450" border="0" src="images/CreatedRepo.png"/>
				<br/>
			</li>
		</ul>
		<h4 id="Clone_a_Git_repository">Clone a Git repository</h4>
		<p>In order to be able to work in a Git repository if you do not want to create a new repository, the first thing to do is to clone this repository. 
			<br/>
			To clone a remote repository, in Capella, you need to select Window / Show view / Other. 
			<br/>
			Then find "Git Repositories" under Git and select Open.
			<br/>
			<br/>

			<img height="350" width="300" align="middle" border="0" src="images/ShortViewGit.png"/>
			<br/>
			<br/>
			This will open a new view in the Capella environment.
			<br/>
			<br/>

			<img height="300" width="850" align="middle" border="0" src="images/GitRepoViewAdd.png"/>
			<br/>
			<br/>
			From this view, it is possible to:
<ul>
				<li>clone a remote Git repository</li>
				<li>create a new local Git repository (not connected to a remote repository)</li>
				<li>add an existing local Git repository (add to the view a repository which have already been cloned locally, or a local repository with no remote)</li>
</ul>
		</p>
		<table border="1">
			<tr>
				<td>
					<p>
						<img height="48" width="48" border="0" src="images/Information.png"/>
					</p>
				</td>
				<td>
					<p><ul>
<li>Creating a local Git repository can be a good way to perform some version control even without having access to a remote repository</li>
<li>If you create a local git repository, do not check the option "Create as bare repository"</li>
</ul></p>
				</td>
			</tr>
		</table>
		<p>To clone a remote repository, choose "Clone a Git repository".
			<br/>
			Then, Capella will ask for the information about the remote repository: 
			<br/>
<b>This information should be provided to you by the people managing the remote repositories</b> 
			<br/>
			<br/>

			<img height="400" width="440" border="0" src="images/CloneGitRepositoryVersionControl.png"/>

			<br/> 
			<br/>
			When all information is provided, select Next.
			<br/>
			Capella will contact the remote repository and retrieve information regarding the existing branches.
			<br/>
			<br/>

			<img height="400" width="440" border="0" src="images/CloneGitRepositoryVersionControl2.png"/>
			<br/> 
			<br/>
			After selecting the branches to clone, use Next.
			<br/>
			Capella will then ask to define where to create the local repository:
			<br/>
			<br/>

			<img height="400" width="440" border="0" src="images/CloneGitRepositoryVersionControl3.png"/>
			<br/> 
			<br/>
		</p>
		<table border="1">
			<tr>
				<td>
					<p>
						<img height="48" width="48" border="0" src="images/Information.png"/>
					</p>
				</td>
				<td>
					<p><ul>
<li>The local repository can be created wherever you want on your computer.</li>
<li>It does not need to be located in MyApp or any specific location.</li>
<li>However, It should not be located in your Capella workspace (projects from the Git repository will then be imported in the workspace if necessary - see below)</li>
</ul></p>
				</td>
			</tr>
		</table>
		<p>Define the target directory then select Finish. 
			<br/>
			Capella will then clone the remote repository and add the repository to the view.
			<br/>
			This view (which can display several Git repositories), display information about:
<ul>
<li>Local and remote branches</li>
<li>Tags</li>
<li>URL of the remote repository</li>
<li>Working Tree (the files and folders which are managed in version)</li>
</ul>

			<img height="400" width="720" border="0" src="images/GitRepoView.png"/>
		</p>
		<h4 id="Share_a_Capella_model_on_Git_and_commit_a_first_version">Share a Capella model on Git and commit a first version</h4>
		<p>Now that we have cloned the remote repository, we are going to add a Capella model to the Git repository for version control. 
			<br/>
			For this, in the Capella Project Explorer, select the Project (folder containing the Capella model) and use right click, Team / Share Project
			<br/> 
			<br/>

			<img height="400" width="500" border="0" src="images/ShareProject2.png"/> 
			<br/>
			<br/>
			This will open a window where we have to define:
<ul>
<li>the repository in which we want to store the Capella model (several options may be possible if you have several repositories in the view "Git Repositories")</li>
<li>define the path within the target repository (if empty, the project will be stored at the root of the repository)</li>
</ul>

			<img height="400" width="640" border="0" src="images/ShareProject3.png"/>
			<br/>
			<br/>
			When done, select Finish. 
			<br/>
			The Project Explorer will now display the name of the repository and the current branch next to the name of the Capella Project.
			<br/>
			<br/>

			<img height="150" width="300" border="0" src="images/RepositoryBranch.png"/>
			<br/>
			<br/>
			Moreover, we can see some question mark on the file and folder icon. This is because so far those files have not yet been committed to the repository.
			<br/>
			To commit a first version of the files, we need to use: Window / Show view / Other
			<br/>
			Then find "Git Staging" under Git and select Open.
			<br/>
			<br/>

			<img height="375" width="300" border="0" src="images/ShowViewGitStaging2.png"/>
			<br/>
			<br/>
			This will open a new view in the Capella environment
			<br/>
			<br/>

			<img height="300" width="758" border="0" src="images/GitStagingView.png"/>
			<br/>
			<br/>
			In this view, we can:
<ul>
<li>select files to be committed (by moving them from Unstaged Changes to Staged Changes)</li>
<li>provide a Commit Message</li>
<li>provide information about the Author and Committer</li>
</ul>
			Here we are going to commit all of the files and provide a description "First commit"
			<br/>

			<img height="300" width="800" border="0" src="images/GitStagingCommit.png"/>
			<br/>
			<br/>
		</p>
		<table border="1">
			<tr>
				<td>
					<p>
						<img height="34" width="32" border="0" src="images/Flag.jpg"/>
					</p>
				</td>
				<td>
					<p>When committing a Capella model, all of the files (*.project, *.afm, *.aird and *.capella) need to be committed consistently in order to avoid corruption of the model!</p>
				</td>
			</tr>
		</table>
		<p>
			<br/>
			Finally, here we have two different options:
<ul>
<li>either Commit (create a new version in the local repository only)</li>
<li>or Commit and Push (create a new version in the local repository, then push the new version in the remote repository as well)</li>
</ul>
			We are going to use the second option here.
			<br/>
			When the push is completed, Capella display a confirmation window.
			<br/>
			<br/>

			<img height="400" width="600" border="0" src="images/PushResult.png"/>
			<br/>
			<br/>
			No action is required here and we can select Close.
			<br/>
		</p>
		<table border="1">
			<tr>
				<td>
					<p>
						<img height="48" width="48" border="0" src="images/Information.png"/>
					</p>
				</td>
				<td>
					<p><ul>
<li>If we choose "Commit" instead of "Commit and Push" then the new version is only defined in the local repository and the remote repository is not updated.</li>
<li>To update the remote repository, we can go in the "Git Repositories" view, select origin under Remotes, and use right click, Push.</li>
<li>This will trigger the push action toward the remote repositor 
						<br/>
						<br/>

						<img height="300" width="700" border="0" src="images/RemoteRepo.png"/>
						<br/>
						<br/>
</li>
</ul>
					</p>
				</td>
			</tr>
		</table>
		<p>Now we can see that the icons in the Project Explorer are modified and display a yellow cylinder to show that the files are committed in the repository
			<br/>
			<br/>

			<img height="150" width="300" border="0" src="images/YellowCilinder.png"/>
			<br/>
			<br/>
			Also, the Capella model can now be found in the Git Repositories view in the Working Tree
			<br/>
			<br/>

			<img height="300" width="540" border="0" src="images/WorkingTree.png"/>
			<br/>
			<br/>
		</p>
		<h4 id="Retrieve_model_from_a_Git_repository">Retrieve model from a Git repository</h4>
		<p>If we initially clone a non-empty repository, we will directly see all its content in the Working Tree.
			<br/>
			If the Working Tree contains Capella models, they can be imported in the Workspace in order to be able to open / modify thembr&gt;
			To do so, you need to select the project in the Working Tree, then use right click, Import Projects
			<br/>

			<img height="300" width="700" border="0" src="images/ImportProject.png"/>
			<br/>
			<br/>
		</p>
		<h4 id="Perform_a_new_commit.2C_retrieve_history.2C_compare_versions">Perform a new commit, retrieve history, compare versions</h4>
		<p>Now lets modify our Capella model to commit a new version of the model.
			<br/>
		</p>
		<p>Once the model is modify, we will see a "&gt;" icon next to the name of the files in the Project Explorer.
			<br/>
			<br/>
		</p>
		<p>This indicate that the files have been modified compared to the last committed version.
			<br/>
			<br/>

			<img height="150" width="300" border="0" src="images/YellowCilinder.png"/>
			<br/>
			<br/>
			At any time, we can use a right click on the aird file, then Compare With to compare the current definition of the model with:
			<br/>
<ul>
<li>HEAD Revision : the last commit in the current branch</li>
<li>Branch, Tag or Reference: to select one specific branch or tag</li>
<li>Commit : to select one specific commit in the history of the repository</li>
</ul>

			<img height="400" width="600" border="0" src="images/CompareHead.png"/>
			<br/>
			<br/>
		</p>
		<table border="1">
			<tr>
				<td>
					<p>
						<img height="34" width="32" border="0" src="images/Flag.jpg"/>
					</p>
				</td>
				<td>
					<p><ul>
<li>Here we see that we can also use the command Replace With.</li>
<li>However, we need to be careful with this command because it will replace the selected file with a previous version.</li>
<li>To ensure the consistency of the model, all files need to be in a consistent state (*.aird, *.capella, *.afm).</li>
<li>As a result, it is recommended to use the command Replace With on the project (folder) instead of on the files to ensure that all files are in a consistent state.</li>
</ul></p>
				</td>
			</tr>
		</table>
		<p>
			<br/>
			When comparing with the HEAD Revision for example, Capella will first display a configuration window:
			<br/>
			<br/>

			<img height="250" width="400" border="0" src="images/DiffMerge.png"/>
			<br/>
			<br/>
			Nothing need to be modified here and we can select Finish. Capella will then open the diff / merge window
			<br/>
			<br/>

			<img height="400" width="650" border="0" src="images/DiffMergeWindow.png"/>
			<br/>
			<br/>
			As a remember we can see here:
<ul>
<li>the current version of the model in the middle panel</li>
<li>the previous commit on the right panel</li>
<li>the list of differences in the left panel</li>
</ul>
			From this window, we can review differences between the versions, and even revert modifications by transferring elements.
			<br/>
		</p>
		<table border="1">
			<tr>
				<td>
					<p>
						<img height="48" width="48" border="0" src="images/Information.png"/>
					</p>
				</td>
				<td>
					<p><ul>
<li>If we select the capella file then use Compare With, we will only see the differences in the model element definitions.</li>
<li>As if we select the aird file, we see the differences in the model element definitions + the differences in the diagrams</li>
</ul></p>
				</td>
			</tr>
		</table>
		<p>To commit a new version in the repository, we need to use the "Git Staging" view again, move the files from Unstaged Changes to Staged Changes and provide a Commit Message.
			<br/>
			<br/>

			<img height="300" width="700" border="0" src="images/GitStagingCommit3.png"/>
			<br/>
			<br/>
			Finally we can use Commit and Push again. The new version is committed in the local and remote repository.
			<br/>
			<br/>
			To see the history of the repository containing the model, we need to use the view "Git Repositories", select the local branch on which we are working and use right click, Show In / History

			<img height="250" width="550" border="0" src="images/ShowHistory.png"/>
			<br/>
			<br/>
			This will open a new window with the list of commits in the branch and the main information.
			<br/>
			When selecting a commit, the full commit message is displayed below with the committed files.
			<br/>

			<img height="300" width="700" border="0" src="images/HistoryView.png"/>
			<br/>
			<br/>
		</p>
		<h4 id="Retrieve_a_new_version">Retrieve a new version</h4>
		<p>Now lets consider that someone else has been working on the model and has pushed a new version.
			<br/>
			This mean that the remote repository has been updated with the new version.
			<br/>
			However, our local repository has not yet been updated.
			<br/>
		</p>
		<table border="1">
			<tr>
				<td>
					<p>
						<img height="34" width="32" border="0" src="images/Flag.jpg"/>
					</p>
				</td>
				<td>
					<p><ul>
<li>There is no notification in Capella that a new version has been pushed to the remote repository!</li>
</ul></p>
				</td>
			</tr>
		</table>
		<p>
			<br/>
		</p>
		<p>The first step is to resynchronize our local repository with the updated remote repository.
			<br/>
			For this, we need to use the window "Git Repositories", select origin in Remotes and use right click, Fetch. 
			<br/>
			<br/>

			<img height="250" width="550" border="0" src="images/FetchImg.png"/>
			<br/>
			<br/>
			This will open a confirmation window with the result of the Fetch
			<br/>
			<br/>

			<img height="250" width="400" border="0" src="images/ConfirmationFetch.png"/>
			<br/>
			<br/>
			Here we have only one new commit in the branch master performed by ADE.
			<br/>
<b>Here we need to be careful!</b>
			The local repository has retrieved the new commits performed. However, our local branch (on which we are working) does not yet integrate all the new commits.
			<br/>
			We can see here that the local branch master and the remote branch origin/master are not at the same state.
			<br/>
			<br/>

			<img height="150" width="500" border="0" src="images/DiffStatesRemoteLocal.png"/>
			<br/>
			<br/>
		</p>
		<p>We can see that our local branch is one commit late with the indication 
			<br/>
			There is also this indication in the Project Explorer next to the project name
			<br/>
			<br/>

			<img height="150" width="300" border="0" src="images/IndicationNext.png"/>
			<br/>
			<br/>
			To integrate the new commits in our local branch (and be able to see the new version of the model), we need to select the remote origin/master branch, then use right click, Merge
			<br/>
			<br/>

			<img height="400" width="650" border="0" src="images/SelectRemoteBranch.png"/>
			<br/>
			<br/>
			In this case, it result in a Fast-forward and the local branch integrate the new definitions of the remote branch
			<br/>
			<br/>

			<img height="200" width="400" border="0" src="images/MergeResult2.png"/>
			<br/>
			<br/>
		</p>
		<h4 id="Merge_conflicts">Merge conflicts</h4>
		<p>In this last case, we are going to consider two different users working on the same model at the same time.
			<br/>
			Both User A and User B start from version 3 of the model and perform modification.
			<br/>
			User A perform his commit and push first. His version is integrated into the remote repository as the new reference version (version 4).
			<br/>
			User B then tries to push is modification. Here the remote repository will not accept his modification because his new version does not use the latest version of the repository (version 4) as starting point, but uses an old version (version 3).
			<br/>
			<br/>

			<img height="250" width="550" border="0" src="images/ConflictImg.png"/>
			<br/>
			<br/>
			Lets see what happen from the point of view of User B.
			<br/>
			User B perform his modification, and then tries to commit and push his modification as usual.
			<br/>
			However, when selecting Commit and Push, he gets the following message:
			<br/>
			<br/>

			<img height="340" width="500" border="0" src="images/PushConflictMessage.png"/>
			<br/>
			<br/>
			His modification cannot be pushed to the remote branch because they are not following the last commit of the remote branch.
			<br/>
		</p>
		<table border="1">
			<tr>
				<td>
					<p>
						<img height="48" width="48" border="0" src="images/Information.png"/>
					</p>
				</td>
				<td>
					<p>Note: with the command Commit and Push, only the push is rejected. But our modifications have been committed toward the local repository</p>
				</td>
			</tr>
		</table>
		<p>
			<br/>
			So we are going to use the command Fetch to retrieve the last modifications performed on the remote repository.
			<br/>
			<br/>

			<img height="250" width="550" border="0" src="images/FetchImg.png"/>
			<br/>
			<br/>
			With this, we are able to retrieve the modifications performed by User A
			<br/>
			<br/>

			<img height="250" width="400" border="0" src="images/FetchMessage.png"/>
			<br/>
			<br/>
			We see now that we are 1 commit ahead of the remote branch, but also 1 commit late:
			<br/>
			<br/>

			<img height="150" width="300" border="0" src="images/ProjectExplorerAird.png"/>
			<br/>
			<br/>
			Now we are going to try to merge our local branch with the remote branch
			<br/>
			<br/>

			<img height="250" width="550" border="0" src="images/MergeLocalWithRemote.png"/>
			<br/>
			<br/>
		</p>
		<table border="1">
			<tr>
				<td>
					<p>
						<img height="34" width="32" border="0" src="images/Flag.jpg"/>
					</p>
				</td>
				<td>
					<p>Before performing the Merge, we need to close the Capella model by selecting the aird file then right click, Close</p>
				</td>
			</tr>
		</table>
		<p>
			<br/>
			Here we see that the merge cannot be easily performed and result in a conflict.
			<br/>
			Capella detects that the same model has been modified by 2 different people and requires a user action in order to manually merge the modifications performed by the different users.
			<br/>
			<br/>

			<img height="250" width="380" border="0" src="images/MergeConflictResult.png"/>
			<br/>
			<br/>
			We can see the elements for which there is a conflict (elements with the double red arrow)
			<br/>
			<br/>

			<img height="150" width="300" border="0" src="images/ViewConflicts.png"/>
			<br/>
			<br/>
			To resolve the conflict, we are going to use a right click on the aird file, then Team / Merge Tool
			<br/>
			<br/>

			<img height="400" width="700" border="0" src="images/MergeToolForConflict.png"/>
			<br/>
			<br/>
			Again we will have a configuration window.
			<br/>
			<br/>

			<img height="250" width="400" border="0" src="images/DiffMergeImg2.png"/>
			<br/>
			<br/>
			Here we don't need to modify anything and we can just select Finish
			<br/>
			We have now a new diff / merge window from which we have to merge the modifications performed by both User A and User B.
			<br/>
			<br/>

			<img height="400" width="700" border="0" src="images/MergeWindow.png"/>
			<br/>
			<br/>
			We can also open the Capella model and perform the merge by modifying elements and diagrams by hand.
			<br/>
		</p>
		<table border="1">
			<tr>
				<td>
					<p>
						<img height="34" width="32" border="0" src="images/Flag.jpg"/>
					</p>
				</td>
				<td>
					<p><ul>
<li>Resolving conflicts in Capella models can be a tedious task if different users have modified the same elements.</li>
<li>This is why Team 4 Capella has been developed and should be used when requiring several people to modify the same model at the same time.</li>
</ul></p>
				</td>
			</tr>
		</table>
		<p>
			<br/>
			When the merge is completed, User B can now perform a Commit and Push to validate the merge.
			<br/>
			Note that the Commit Message is automatically pre-filled to indicate that we have performed a merge.
			<br/>

			<img height="350" width="700" border="0" src="images/Pre-fieldCommit.png"/>
			<br/>
			<br/>
			The Push will now succeed
			<br/>
			<br/>

			<img height="300" width="400" border="0" src="images/SuccesPush.png"/>
			<br/>
			<br/>
			We can now check the history of the local branch which describes that modifications have been performed in parallel
			<br/>
			<br/>

			<img height="350" width="700" border="0" src="images/HistoryCheck.png"/>
			<br/>
			<br/>
		</p>
		<h3 id="Advanced_Tutorial">Advanced Tutorial</h3>
		<p>This is a continuation of the above basic tutorial.</p>
		<h4 id="Create_a_tag">Create a tag</h4>
		<p>Like most VCSs, Git has the ability to tag specific points in history as being important. Typically people use this functionality to mark release points (v1.0, and so on). In this section, you’ll learn how to create new tags.</p>
		<ul>
			<li>Open the History View and right-click on the commit you want to tag</li>
			<li>Click 
				<b>Create Tag...</b> in the menu
				<br/>
				<br/>-
				<img height="400" width="450" border="0" src="images/CreateTag.png"/>
			</li>
		</ul>
		<p>
			<br/>
		</p>
		<dl>
			<dd>-
				<img height="330" width="550" border="0" src="images/TagV1.png"/>
			</dd>
		</dl>
		<ul>
			<li>Enter the tag name "V1.0"</li>
			<li>Enter the tag message "Version 1.0"</li>
			<li>Click 
				<b>Create Tag</b> to create the annotated tag
			</li>
		</ul>
		<p>Tags can also be created from the team menu, click 
			<b>Team &gt; Advanced &gt; Tag...</b>, enter the tag name and message, select the commit you want to tag (default is HEAD) and click OK.
		</p>
		<h4 id="Resolve_Conflicts">Resolve Conflicts</h4>
		<p>Conflicts arise when contradicting changes have been made in parallel and an attempt is made to integrate (merge) them. With Git, this may happen for example when two branches are 
			<b>merged</b>, when a branch is 
			<b>rebased</b> on another, or when a 
			<b>pull</b> is done.
		</p>
		<table border="1">
			<tr>
				<td>
					<p>
						<img height="34" width="32" border="0" src="images/Flag.jpg"/>
					</p>
				</td>
				<td>
					<p>In any case, the session must be closed before the conflict resolving step. This is because during this step, the model contains elements in conflict state, further actions on the session would make the model become completely corrupted.
						There are two mechanisms implemented in Capella to make sure that the session is closed during this step:</p>
					<ul>
						<li>When a model is in conflict state, the session cannot be opened, a popup is displayed to inform users about resources being in conflict.</li>
						<li>An already opened session will automatically be closed if a concerning resource enters the conflict state (e.g. following a Git action).</li>
					</ul>
				</td>
			</tr>
		</table>
		<ul>
			<li>Commit the changes done before with the message "Added Transmit", including the renaming of the function. Be sure to select both .aird and .capella files.</li>
		</ul>
		<ul>
			<li>Right-click the project &gt; Team &gt; Switch to &gt; New branch..., type "maintenance" and validate.
				<br/>
			</li>
		</ul>
		<p>
			<b>You are now in branch "maintenance"</b>.
			<br/>
			<br/>
		</p>
		<dl>
			<dd>-
				<img height="400" width="500" border="0" src="images/SwitchNewBranch.png"/>
			</dd>
		</dl>
		<p>
			<br/>
		</p>
		<ul>
			<li>Close the session (right-click the .aird file and select "Close"). This is because we are going to modify the content of the filesystem.</li>
		</ul>
		<ul>
			<li>In the History view, right-click the "First changes" commit, right-click "Reset" &gt; "Hard". Branch "maintenance" has been moved back to this past commit.
				<br/>This will reset the current branch head to "First changes" commit. It resets the index and working tree. Any changes to tracked files in the working tree since "First changes" commit are discarded.
				<br/>
				<br/>
			</li>
		</ul>
		<dl>
			<dd>-
				<img height="400" width="500" border="0" src="images/ResetHard.png"/>
			</dd>
		</dl>
		<p>
			<br/>
		</p>
		<dl>
			<dd>-
				<img height="200" width="600" border="0" src="images/MaintenanceHead.png"/>
			</dd>
		</dl>
		<p>
			<br/>
		</p>
		<ul>
			<li>Open the model again, rename the function again with a different name, add another function and commit. </li>
		</ul>
		<ul>
			<li>In Window &gt; Preferences &gt; Team &gt; Git &gt; History, select "All branches and tags" and click OK.</li>
		</ul>
		<ul>
			<li>In the History view, you can now see the two branches "master" and "maintenance" that have parallel commits. </li>
		</ul>
		<p>
			<b>We are going to merge branch "master" into branch "maintenance"</b>.
			<br/>
			<br/>
		</p>
		<dl>
			<dd>-
				<img height="200" width="600" border="0" src="images/BothBranches.png"/>
			</dd>
		</dl>
		<p>
			<br/>
		</p>
		<ul>
			<li>Close the session again. </li>
		</ul>
		<ul>
			<li>Right-click the project and click Team &gt; Merge..., select "master" then "Merge".
				<br/>
				<br/>-
				<img height="650" width="550" border="0" src="images/Merge.png"/>
			</li>
		</ul>
		<p>
			<br/>
		</p>
		<dl>
			<dd>-
				<img height="450" width="550" border="0" src="images/MergeDialog.png"/>
			</dd>
		</dl>
		<ul>
			<li>A conflict dialog shows up, click OK.
				<br/>
				<br/>-
				<img height="180" width="450" border="0" src="images/MergeResult.png"/>
			</li>
		</ul>
		<ul>
			<li>A red icon identifies the conflicting files, here the .aird and .capella files.
				<b>They are identified as conflicting because they have been modified in both branches</b>.
				<br/>
				<br/>-
				<img height="275" width="400" border="0" src="images/ConflictFiles.png"/>
			</li>
		</ul>
		<ul>
			<li>Right-click the .aird file and select Team &gt; Merge Tool.
				<br/>
				<br/>-
				<img height="650" width="600" border="0" src="images/MergeTool.png"/>
			</li>
		</ul>
		<p>
			<br/>
		</p>
		<dl>
			<dd>-
				<img height="300" width="600" border="0" src="images/DiffMergeDialog.png"/>
			</dd>
		</dl>
		<ul>
			<li>Click OK: 
				<b>the Capella diff/merge tool shows up</b>. You may only modify the model on the left-hand side, which is initialized with the content it has in branch "maintenance". On the right-hand side, you can see its content in the "master" branch. You may only report changes from the "master" branch to the "maitenance" branch. In the end, the content on the left-hand side will be considered as the merged content.
			</li>
		</ul>
		<ul>
			<li>Click the "Difference Categories" button in the "Synthesis" section: a dialog opens that allows filtering differences.
				<br/>
				<br/>-
				<img height="400" width="1000" border="0" src="images/DiffMergeEditor.png"/>
			</li>
		</ul>
		<ul>
			<li>
				<b>Let us report all elements that were added in the "master" branch</b>. Set the "Added elements" with the right-to-left blue arrow icon to "Focused" mode and click OK: only those differences are now shown.
				<br/>
				<br/>-
				<img height="400" width="550" border="0" src="images/DifferenceCategories.png"/>
			</li>
		</ul>
		<ul>
			<li>Select all root elements in the "Synthesis" section and click the "Copy to the left" merge button, the one with the left-to-right arrow icon. Done!
				<br/>
				<br/>-
				<img height="300" width="1000" border="0" src="images/CopyToLeft.png"/>
			</li>
		</ul>
		<ul>
			<li>
				<b>Let us now focus on real conflicts</b>, i.e., conflicts at the granularity of model elements. Re-open the "Difference Categories" dialog, reset the "Added elements" category to "normal" mode and set the "Conflicts" category to "focused" mode, then press OK.
				<br/>
				<br/>-
				<img height="400" width="550" border="0" src="images/DifferenceCategoriesConflicts.png"/>
			</li>
		</ul>
		<ul>
			<li>There is one real conflict: the parallel renaming of the function. You can now see it in both the model and the diagram. Let us first ignore the diagram since in this case it will be able to synchronize with the model.</li>
		</ul>
		<ul>
			<li>Select the diagram in the "Synthesis" view and click the "Ignore on the left" button, the one with the check box icon.
				<br/>
				<br/>-
				<img height="300" width="1000" border="0" src="images/IgnoreDiagramConflicts.png"/>
			</li>
		</ul>
		<ul>
			<li>Click the "Next model difference" navigation button, the one with the downward arrow.
				<br/>
				<br/>-
				<img height="300" width="1000" border="0" src="images/NextModelDiff.png"/>
			</li>
		</ul>
		<ul>
			<li>The only difference left is selected, which corresponds to the renaming in the model. You have the choice to either keep the name from the "maintenance" branch on the left, or report the name of the "master" branch on the right. Click the "Copy to the left" merge button to opt for the second solution.
				<br/>
				<br/>-
				<img height="300" width="1000" border="0" src="images/CopyToTheLeft.png"/>
			</li>
		</ul>
		<p>
			<br/>
		</p>
		<dl>
			<dd>-
				<img height="300" width="1000" border="0" src="images/ModelMerged.png"/>
			</dd>
		</dl>
		<ul>
			<li>
				<b>You may now consider the model as merged</b>. Press Ctrl-S to save then close the diff/merge editor. You now have to inform Git that the merge is finished. 
			</li>
		</ul>
		<table border="1">
			<tr>
				<td>
					<p>
						<img height="34" width="32" border="0" src="images/Flag.jpg"/>
					</p>
				</td>
				<td>
					<p>Please make sure that all the conflicts have been resolved before leaving the Merge Tool editor. Any unresolved conflict could lead to a corrupted model.
						If somehow the conflict resolving process ends up with a corrupted model and you want to get back to the previous commit, you could just commit the current modification and apply a "Reset" &gt; "Hard" action (an example of this action has been shown in one of previous steps in this tutorial).</p>
				</td>
			</tr>
		</table>
		<ul>
			<li>Switch back to the Git perspective, select the repository and select the "Git Staging" view at the bottom. You should see the .aird and .capella files in the "Unstaged Changes" section.
				<br/>
				<br/>-
				<img height="375" width="1000" border="0" src="images/GitStaging.png"/>
			</li>
		</ul>
		<ul>
			<li>Drag and drop these files to the "Staged Changes" section to mark them as merged, then click the Commit button. The merge is officially finished.
				<br/>
				<br/>-
				<img height="375" width="1000" border="0" src="images/StagedChanges.png"/>
			</li>
		</ul>
		<ul>
			<li>Switch back to the Capella perspective and select the "History" view: you can see through the lifelines that you have successfully merged the branches.
				<br/>
				<br/>-
				<img height="175" width="625" border="0" src="images/MergedBranches.png"/>
			</li>
		</ul>
		<ul>
			<li>Open the System Data Flow diagram: you can see that the contributions of the two branches have been integrated and the rename conflict has been resolved in favor of the "master" branch. You can also see that the editor is in dirty mode (save is enabled): this is because the diagram has automatically updated itself to reflect the change to the name.</li>
		</ul>
		<h4 id="Fragmented_Model">Fragmented Model</h4>
		<p>If you are not familiar with Capella model fragmentation, you can refer to 
			<a href="/wiki/../help/topic/org.polarsys.capella.doc/html/Fragment%20management/Fragment%20management.html" title="../help/topic/org.polarsys.capella.doc/html/Fragment%20management/Fragment%20management.html">Fragment Management</a>
		</p>
		<p>When your model is fragmented, you have to select all your fragments in your commits and always use the root aird for compare operation.</p>
		<h4 id="Model_with_libraries">Model with libraries</h4>
		<p>If your model refers to libraries, you have to include manually your modified libraries in your commits in order to keep your model valid.</p>
		<h2 id="Limitations_.2F_Known_Issues">Limitations / Known Issues</h2>
		<ul>
			<li>Diff/Merge 3-way can be improved.</li>
			<li>The session needs to be closed prior to any Fetch, Pull or Rebase. This is due to the fact that files will be changed by Git and those changes need to be synchonized with the Eclipse File System.</li>
			<li>On a fragmented model, Diff/Merge needs to be performed on the root file (not the airdfragment/capellafragment) to ensure that the model is fully loaded during the Diff/Merge analysis.</li>
		</ul>
	</body>
</html>